Your Universal Remote Control Center
RemoteCentral.com
Philips Pronto Professional Forum - View Post
Previous section Next section Up level
Up level
The following page was printed from RemoteCentral.com:

Login:
Pass:
 
 

Topic:
Strange behaviour of Rfx9600+Tsu9600
This thread has 11 replies. Displaying all posts.
Post 1 made on Tuesday January 1, 2013 at 09:09
Fbrighi
Long Time Member
Joined:
Posts:
September 2010
52
Hello,

I looked at several discussions about this matter, but didn't find the same "strange" behaviour i'm experiencing.

I have a tsu9600 + rfx9600, extender is workin in network mode on a dedicated lan (and wifi). Ip are dynamic (dhcp), encryption is wep and the router is d-link. Sometimes, when i power up the extender and the tsu9600, pressing any button the busy led on rfx9600 remains active (also if command is single and not a macro execution) and tsu reports comman failed. The only way to solve is to power down extender and power up again...sometimes for several times before system starts working.

Once started working, it is full ok (i use both ir and serial codes + prontoscript programs).

I suspect the problem is some setup issue, but don't be able to fix till now. Has anybody experienced similar behaviour? Firmware on both units are the latest ones available.

Thank you for any type of help

Br
Fkb
FKB
Post 2 made on Tuesday January 1, 2013 at 10:43
Lowpro
Select Member
Joined:
Posts:
March 2004
2,081
I experienced the issues you've described with one of my RFX9600's due to a firmware issue. In this case it was a used extender I had purchased and was getting setup for the first time. The latest official release for the RFX9x00 is 1.4.7 if I am not mistaken which is what I'm running on all of my extenders. Firmware version 1.4.8 is a beta release put out just prior to Philips closing the Pronto division. I'm sure someone will correct me if I'm wrong. That being said, irrespective of what firmware version you are running on your RFX9600 it still wouldn't hurt to flash the firmware again. I would imagine an IP address conflict could also result in the issues you've described. Personally I'd dump the DHCP for your Pronto gear and go with static IP addresses outside the range of your DCHP pool.
LP Related Links:
View my profile to access various
links to key posts and downloads.
OP | Post 3 made on Wednesday January 2, 2013 at 11:18
Fbrighi
Long Time Member
Joined:
Posts:
September 2010
52
Hello, thank you for the help. Yes, I have latest philips official firmware loaded into both extender and tsu9600, i preferred not to load the newer beta version due to i didn't trust it, since it was not an official full tested solution.

I have set up static ip for both remote&extender this morning, using .31 and .41 respectively last digits in the addresses. I tried three times power on/off system to test if the issue was still present...up to now system worked correctly without any blocking/busy light permanently actived. I'll keep attention during use, if problem is still present and in case i will let you know.

Thank you for the suggestion you gave me :).

Best regards,

Fkb
FKB
OP | Post 4 made on Tuesday January 29, 2013 at 05:03
Fbrighi
Long Time Member
Joined:
Posts:
September 2010
52
Hello again,

I resumed this discussion because, despite I was thinking problem was solved, yesterday it came up again.
Until now i have taken up all possible countermeasures, so :

- I put fixed Ip for all network devices, Tsu9600 and RFX9600 moreover have static IP (.31 & .41) very far from other standard devices (.1 -.5).

- I re-flashed firmware to both devices. I also flashed latest beta available for RFX9600 (1.4.8), and latest for Tsu9600 (7.3.3).

- I checked w-ifi settings, and they are correct (g-only, wep encription ecc)

Up to now the problem seems to be very reduced, but still present. In practice, it still happens sometime that, after powering up router - Rfx9600 and for final TSU9600, when sending a command "command failed" is reported, while busy light of extender remains active for approx 20-30 sec and then it goes off. But it happens very few respect to before.

Yesterday i discovered that if I shut down the Tsu9600, and then power it on again, problem seems disappear. Usually until now i was usual to power down rfx9600, due to busy light on...but it goes down by itself after some second.

So it seems there is some issue between TSU9600 and router (Dlink 1364, if i remember correct). I have noted also, that if at starting up I go to protoscript page, all automatic serial commands are correctly executed (at least, extender led are showing regular Rs port traffic, without busy light to stay active) ... problem seems to raise up when i push any button.

Anyone has additional suggestion on what can be tried also?

Additional question, since it seems that restarting tsu9600 can solve ... is there any way to restart the tsu9600 without using I-O button? I mean, a procedure to simply reboot/restart device (not to restore factory default).

Thank you and best regards,
FKB
FKB
Post 5 made on Tuesday January 29, 2013 at 13:23
gopronto
Senior Member
Joined:
Posts:
April 2008
1,453
hi change you rfx firmware to 1.4.7 and make sure the pronto is ver 7.3.3 and use PEP v2
Pronto still one of the best Wi-Fi Remotes,
www.ikonavs.co.nz and [Link: axiumcontrol.com] Axium Control
OP | Post 6 made on Wednesday January 30, 2013 at 04:02
Fbrighi
Long Time Member
Joined:
Posts:
September 2010
52
Hello,

Thanks for suggestion, I'll try it.

Additional thing that I discovered only yesterday. I noted that, any button I have created that is programmed through Prontoscript (i.e. sending serial command with serial1.send code), never creates "command failure". It seems that this way of execution is not "busying" the extender and is always recognized (in fact 2-way communication between TSU9600 and Oppo blu ray are always guaranteed). If this is true, my problem would be completely solved, since I'm using TSU9600 as "control" center for Home Cinema components...not to control singularly each of them.

But, at the present time, since all 4 Rs232 port are used, one device (the image processor Lumagen radiance) is still controlled through IR code. Due to this, all the actions that involve it (mainly the CMS selection) have to be recalled by prontoscript using a command like : widget("MASKING FLAT").executeActions();
where "MASKING FLAT" is an existing IR programmed button. My doubt is that, also using prontoscript for this device, commands that use this "format" are anyway subjected to the "command failure" event. Is this really true?

Additionally...all the issues would be solved if one rs232 port could be "split" in two (of course 1 way only), so to let possible control two devices on the same port (for example, Lumagen and Lights system, that have different string codes and same port transmission parameters). Does anyone found/tried Rs232 split module? If yes, where can I find it? I tried asking some collegues electronic engineer...but i hadn't clear answer on that :-S

Thanks to all of you :-)
FKB
FKB
Post 7 made on Thursday January 31, 2013 at 01:48
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
13,006
by chance are you using a page script or scheduleAfter to poll a 232 port?
Lyndel McGee
Philips Pronto Addict/Beta Tester
OP | Post 8 made on Thursday January 31, 2013 at 02:43
Fbrighi
Long Time Member
Joined:
Posts:
September 2010
52
Hello, yes I'm using a page script that is repeated every 2 seconds. This is continuous monitoring 2 Rs232 ports, when it founds certain "values" from these Rs232, it executes certain actions (all serial.send commands).

For hard keys, I use as well serial.send commands, when I need to command the IR device (Lumagen), I use : widget("NAMEOFIRBUTTON").executeActions;
I don't use scheduleActions, because it is not working...if i try to use it within a script it is simply ignored and script is terminated.

I noted that using prontoscript programmed buttons, command failed is never coming out (busy on extender never light up as well). If I send direct command (i.e. a button that recalls command from programmed device list, IR, serial or whatever), command failed may come out.

For test yesterday evening i "resumed" my old RFX9400...issue on it is not present, also sending direct commands...no command failure ever reported.

FKB

Last edited by Fbrighi on January 31, 2013 08:20.
FKB
Post 9 made on Thursday January 31, 2013 at 19:12
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
13,006
Comment out the page script and see if the problem goes away. The busy light only comes on when you are sending non-script actions from an actionlist. This comes from a Lock/Unlock request that go from Pronto to Extender. ProntoScript extender script functions don't lock/unlock as they only execute one thing at a time. If you have any outstanding (with timeout of fairly large falue) serial.waits or serial.receives, that may be the issue. IIRC, those actually will be cancelled when a non-script request comes in. Your script will get an error and you may seen command-failed.

See here:

[Link: remotecentral.com]

And if scheduleAfter() is not working, then I suggest you put a try/catch block and some debug logs inside your function that is being called and work out why it does not work.

There are plenty of examples on this forum on how to do this, many posted by me (debugging tips).
Lyndel McGee
Philips Pronto Addict/Beta Tester
OP | Post 10 made on Friday February 1, 2013 at 08:02
Fbrighi
Long Time Member
Joined:
Posts:
September 2010
52
Hello, thanks for the help. What do you mean exactly with "comment out"?

To add one fact, "command failed" occurs also when using "direct" butons in the home page (where no script is running) ... then i go on the page that executes continuously the script and all work good.

To summarize, it seems problems are related only to "direct" commands from tsu9600 to rfx9600. Rfx9400 is free of that. Still to check if IR command recalled by prontoscript suffer the issue or not.

FKB
FKB
Post 11 made on Friday February 1, 2013 at 08:34
Lyndel McGee
RC Moderator
Joined:
Posts:
August 2001
13,006
It means to comment out or stop using your script in the pages.

I will suggest that you specify the 'IP' address of the extender in PEP. It may be that you have the IP addy specified for RFX9400 but not for RFX9600? I know they are on same gateway and subnet but what is not known at this time is how many hops of UDP multicast it takes to get to where extender can be identified. By specifying the IP for an extender, you bypass the multicast. However, there is one interesting part. If you do it for 1 extender, you must do it for all (at least that was the requirement in PEP1).
Lyndel McGee
Philips Pronto Addict/Beta Tester
OP | Post 12 made on Friday February 1, 2013 at 08:47
Fbrighi
Long Time Member
Joined:
Posts:
September 2010
52
Yes, I specified both IP address (RFX9400 & 9600) in the PEP. I tried also specific channel on WiFi setting, but without luck.

In few hours I'll try with a new configuration, using only script. If no luck even for it, I'll install also RFX9400 and use it for Lumagen IR control. Complex layout, but divinding IR from serial control outputs is an idea that I like.

FKB
FKB


Jump to


Protected Feature Before you can reply to a message...
You must first register for a Remote Central user account - it's fast and free! Or, if you already have an account, please login now.

Please read the following: Unsolicited commercial advertisements are absolutely not permitted on this forum. Other private buy & sell messages should be posted to our Marketplace. For information on how to advertise your service or product click here. Remote Central reserves the right to remove or modify any post that is deemed inappropriate.

Hosting Services by ipHouse